improving testing on marionette/backbone #29
Conversation
| @@ -476,15 +476,34 @@ We have extended Sinon with a few custom functions, which you can see in django/ | |||
|
|
|||
| ### Running the Jasmine Tests | |||
|
|
|||
| Go to <https://www.evbdev.com/js-tests> to see the index of the JS unit test suites. Most of the modern unit tests are under require at <https://www.evbdev.com/js-tests/require>. | |||
| We have several system cohexisting in our testing environment and depending on our runner version is how we run them. | |||
There was a problem hiding this comment.
May reword to say:
We have several systems that coexist in our testing environment, and the version of the test runner determines how the tests are executed.
| |:--------------------------------|:--------------:|--------------------------------------------------------| | ||
| | `mako`, `js`, global name space |1.2.0 | `tug attach core-web && test_eb ebapps.js_tests.tests`| | ||
| | `handlebars`, `js` |1.2.0, 2.5.0 | `tug attach core-frontend && npm run tests` | | ||
| | `react` + `jsx` + `es6` |2.5.0 | `tug attach core-frontend && npm run tests` | |
There was a problem hiding this comment.
should be:
react,jsx,es6
(separate by commas instead of +)
| ### known issues | ||
|
|
||
| ####rendering on the Dom | ||
| jasmine comes with a handy `setFixture()` function that attaches html to the runner so we can render there and try our code. this results often in issues with what we leave behind or conflicts with the actual runner report. |
There was a problem hiding this comment.
Jasmine comes with a handy
setFixturefunction that attaches HTML to the runner so that we can render there and test our code. This often results leaks in the DOM or conflicts with the actual runner report.
| ####rendering on the Dom | ||
| jasmine comes with a handy `setFixture()` function that attaches html to the runner so we can render there and try our code. this results often in issues with what we leave behind or conflicts with the actual runner report. | ||
|
|
||
| solution: it most cases the solution for us is just to create a fake node (not attached to the dom) ex: |
There was a problem hiding this comment.
"in" instead of "it"
| jasmine comes with a handy `setFixture()` function that attaches html to the runner so we can render there and try our code. this results often in issues with what we leave behind or conflicts with the actual runner report. | ||
|
|
||
| solution: it most cases the solution for us is just to create a fake node (not attached to the dom) ex: | ||
| `new Marionette.ItemView(el: $(<div id=fake ></div>)`) |
There was a problem hiding this comment.
I'd put this in a code block instead of inline code
| `new Marionette.ItemView(el: $(<div id=fake ></div>)`) | ||
|
|
||
| ####avoiding toBeVisible | ||
| Jquery does several tricky things to find out if an element is hidden or not. assuming that an element is attached to the dom. it also leads to confusing tests, giving that not always the element we are testing gets hidden by direct result of our test case rather is produced by the parent element or css generically applied. |
There was a problem hiding this comment.
Here's the best rewrite I could come up with:
jQuery does several tricky things to find out whether or not an element is hidden (assuming that an element is attached to the DOM). This means that a test could successfully verify that an element is hidden even if the test itself never hid the element. This is because the test made an ancestor element hidden, so the child element also became hidden. Or worse, a previous test hid the ancestor element and the current test is implicitly relying on that element being hidden. Avoid
toBeVisiblehelps prevent this weird test cases.
gagoar
force-pushed
the
testing-known-issues
branch
from
100eb20 to
d910dc6
Compare
|
Should we close this PR? |
WIP, but the info is there.
the table looks like that